Okay.
So today we are going to have a look at remote functions.
They are very similar to remote events but have a bit more to them.
Okay.
So remote functions um basically allow information to be sent back, um, after the server or after
the client has been fired.
So with remote events, you can pass information from the server to the client or from the client to
the server, but you can't pass it back over again.
You kind of have to in that case, use two different ones and it can get a bit confusing what you're
passing over and when.
Um, however, a remote function allows you to pass information over, let's say from the client to
the server.
And then the server does some bits, and then it passes it back over to the client to continue off,
continue going basically.
So um, so a really neat feature and you can probably save you a bit of time when instead you might
have to use two or a couple different remote events.
Okay.
Um, so remote functions, just like remote events go inside replicated storage.
So go over to there and put in a remote function like that there.
Okay.
And then let's add in a um I'm going to do this using a click detector actually.
Um, so let's go add a part and add in a click detector to that part.
Now click detectors are done locally, but don't be tempted to add a local script in here because local
scripts don't run in the workspace.
Have to put it somewhere else.
I'm going to put it into starter player scripts here.
Okay.
And here I obviously want to reference replicated Storage again, just like in last lesson.
Um.
Good storage and then also the remote function.
I did mention last lesson, but of course, call the remote function whatever you'd like.
Okay.
Um.
You'd want to call it relevant to what it's storing.
So if, for example, this is allowing you to invisibility potion example I use last lesson, I would
call the remote event something like potion drank so that we know when we're flying it we know what's
going on basically.
So don't call it something random.
Don't keep it as a remote function, give it a different name of always wanting to do okay.
So web storage and just like how with remote events you need to use wait for child because they take
that bit extra time to load remote function there.
Okay cool.
Let's reference the click detector.
So local click detector.
Detector and is equal to game dot workspace dot particle detector.
Okay.
So click detectors where looks at those.
You script those by saying referencing it and using mouse click connect function.
And we'll get the player who's clicked there as well.
Okay.
Um, cool.
So um, let's say um hmm.
Okay.
So basically how this works is we can make some kind of variable, um, which we pass over to the server.
The server does something to that variable, passes it back, and then we use it, use that variable
later on in our local script.
So um, let's call this variable result for example sake okay.
And we make this equal to the remote function.
We don't say fire server.
We say invoke server okay.
Um different terminology, but we're doing the same thing.
Basically the only difference is we're getting it back afterwards.
And here we'd pass over any kind of information.
Now I think let's make this a bit more useful than just, um, doing something very basic.
I'm going to, um, pass over the player like that there.
Um, or it gets that.
It gets it anyway, actually.
So let's not do the player, um, let's do um, let's, let's pass over 50, for example.
Okay.
Um, cool.
So we're going to revisit this, but that's everything we need to do on that to start off with.
We then need to go over to the server.
So let's add a server script into server script service and copy over the same very first two variables.
Like that bear.
Okay, so, um, we then need to basically receive, um, this, um, signal when it is fired.
So just like how with remote events, they are similar to remote events.
Really?
Um, you would reference your motor function and we're going to say on server invoke.
And of course, um, if we're doing it, doing it the other way, which I'll explain later.
You shouldn't be.
Um, you could use on Client Invoke, but you shouldn't be doing it that way.
I'll explain why later on.
Okay.
Um, and this invoke function, you make it, um.
You don't.
You wouldn't you wouldn't use a code on Kinect.
Um, standard way we do it, we connect it slightly different way by making it equal to a new function,
which we would have the player here passed over automatically, and any kind of data we use like that
there.
So different formats.
Um, the reason is basically because we want to return the information and events don't allow us to
return events, just we don't we're not once we've finished using an event, you can't really do anything
else with it.
Whereas when you make it equal to it like this here, I can then later on go return any kind of information
like that there, which is what we're going to be doing basically later on.
So we can then get this data and do whatever we'd like with it.
So I'm going to, in this case take the data, which in this case is a number.
I'm going to just call this number.
I'm going to say a number is equal to the number times by two.
I'm going to double the number.
And then um, let's say um, let's do something with a player just so we're aware of it.
It works.
So what?
So you do whatever code you want to run in this remote function here.
Um, and then once you've done, you can return.
Um, we've looked at returning a while ago, but, um, yeah, you would return any kind of data type
that you want to pass back over to the local script.
So, um, in this case, let's return a string, but let's return say, um, the, um, player dot name
with.
The number.
Um.
Like that they're okay to string is a, um, function haven't explained yet.
Um, you have a couple of different variations.
Um, there is two string and two number.
Basically two string will convert um, a data type.
So a boolean, a number, anything like that to a string is all it does basically.
Um and then two number does the same kind of thing.
It converts like a um any other data type.
So that's usually like a string which contains a number to a number itself.
So they are quite useful to use sometimes, and especially when you're concatenating the string like
this here.
So it's going to return the players name as a string obviously.
And it's going to concatenate it with the number that it's done, just so we can see how um, the times
it by two is affected it on the server.
And I think as well I might just include a space between.
Um, just so it's laid out a bit nicer.
Like right there.
Okay, cool.
So that's everything we want to do on the server.
Let's go and go back to the client.
And once we get to here, um, we can then just carry on like nothing happens and do whatever we'd like
with this result.
So let's just print the result like this here to see what happens.
Okay.
And once you've done that, we can go ahead and give it a go.
So let's play the game.
Um, and have a look.
Probably didn't leave enough time is oh no sorry.
It's on click click.
So that's fine.
Okay.
Let's give it a go.
And it's my player name here with 100 next to it.
Okay, cool.
So it works.
Okay.
Um, now, obviously this isn't some, like, um, incredible new method to use or whatever.
Um, it's just printing my name with a number next to it.
Hopefully you understands the idea that that occurred that to happen basically.
So we're starting from a local script.
When the click detector is pressed, we are invoking the server with information we want to pass over
and we're invoking it with a number.
We then go over to the script and in in this in the server we do some more stuff and we return back
the player name, but originally fired this and a number next to it, which went back to my local script.
We then print it.
So an example of a use for this is basically it has similar uses to remote events, but you would use
it when you want to pass information back over.
So, um, let me think of an example for this.
Let's say this.
Let's say, um, the player presses a button.
Um.
Yeah.
Okay.
Let's say the player presses a button.
The button on the on the on the client.
Okay.
When it occurs, it, um, fires over the server to on server, we will determine how many players there
are in the game, which then fires back to the client which opens, which adds in, adds in a text label
which tells the player how many active players there are, for example.
Okay, so something that you would would otherwise have to use to remote events for can just be done
into one by using remote events and sorry, by using remote functions rather than remote events.
Okay.
Um, now earlier I explained why you should never use this, um, from the server to the client and
then back to the server.
And I think the roadblocks dev them.
Um, what gives an overview of a lot of, a lot of these things.
And it gives a really good explanation of this.
But basically we the reason why is because, um, when you're doing client server client communication,
um, the client is relying on the server.
If something happens to the server, the client won't then receive, um, the value of this variable.
So it will kind of be just left waiting basically.
Um, now this is fine because there aren't issues with the server, but if a server, if a server is
shut down, um, then the client is not going to still exist basically.
So if if there's nothing on the server or clients are gone anyway, so it doesn't matter.
But when you flip it around and you're passing information over from the client, from a server to a
client, and then back to the server, say the client does that, and in the process it decides to leave
the game.
Well, the server is um, then in a state where it can't do anything because the server is expecting
some feedback, some some information back from the client, which no longer exists.
So the server is going to be left waiting in a kind of in that kind of state, um, which is why you
should never use VS, never use VS for server to client to server communication only for client to server
to client communication.
Okay, I can't think of any uses really with from server to client to server.
Um, but if we do find some uses in your tempting and using it, don't.
It's very good.
It's very bad practices to have in your game something as simple as your player losing connection or
your player deciding to leave can break your game, so don't use it.
Okay, um, but yeah, hope this is this has been useful for you to understand remote events and remote
functions in a good bit of detail.
Um, while, um, applications are definitely very important, so definitely try out applications of
these.
Um, and remember you can change the names of remote function.
You can change the names of the variables.
You can run whatever code you like.
Anything you previously learned you can apply to remote events and remote functions.
They just allow more possibilities.
Really?
Okay.
Um, but yeah, they're really essential.
So definitely try things out and make sure you are quite confident on these, as this is one of the
things which you'll be, which you'll be looking at doing quite a few times.
Okay.
And um, in the following lessons, we are going to look at some applications of what we already know
elsewhere.
So in the next lesson we're going to have a look at data source which allow you to save data.
That's a really big topic.
A lot of people are interested in saving their data.
So a very common thing.
Most games save your data.
So join me in the next lecture when we have a look at that.